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Abstract:  This  work  assessed  the  potential  for  development  of  a  building 
automation  system  (BAS)  specification  (for  heating,  ventilating,  and  air 
conditioning  systems,  etc.)  based  on  the  BACnet®  communications 
protocol.  Although  BACnet  is  widely  supported,  no  BAS  specification 
exists  that  implements  BACnet  as  an  Open  System.  The  BACnet  protocol  is 
detailed,  includes  comprehensive  requirements,  and  also  provides  options 
in  how  individual  vendors  might  choose  to  implement  it.  Such  vendor- 
specific  choices  can  effectively  close  the  system  to  future  open  bid 
procurements,  or  result  in  incompatible  systems.  This  work  concluded 
that  implementing  BACnet  in  an  Open  manner  will  require  extensively 
prescriptive  requirements  with  a  large  amount  of  design  and  contract 
documentation.  The  resulting  system  may  not  integrate  as  tightly  as 
desired  and  may  therefore  not  be  as  user  friendly  to  Army  installation 
operations  and  maintenance  (O&M)  staff  as  other  equivalent  systems  due 
mainly  to  the  need  for  multiple  configuration  tools.  This  work 
recommends  that  development  of  BAS  specifications  based  on  BACnet 
continue  and  that  a  source  selection  process  that  pre-qualifies  BACnet 
contractors  be  developed  to  help  obtain  open  systems  in  accordance  with 
those  specifications. 


DISCLAIMER:  The  contents  of  this  report  are  not  to  be  used  for  advertising,  publication,  or  promotional  purposes.  Citation 
of  trade  names  does  not  constitute  an  official  endorsement  or  approval  of  the  use  of  such  commercial  products.  All  product 
names  and  trademarks  cited  are  the  property  of  their  respective  owners.  The  findings  of  this  report  are  not  to  be  construed  as 
an  official  Department  of  the  Army  position  unless  so  designated  by  other  authorized  documents. 

DESTROY  THIS  REPORT  WHEN  NO  LONGER  NEEDED.  DO  NOT  RETURN  IT  TO  THE  ORIGINATOR. 
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Executive  Summary 

The  Engineer  Research  and  Development  Center,  Construction  Engineer¬ 
ing  Research  Laboratory  (ERDC-CERL)  was  tasked  by  Headquarters,  U.S. 
Army  Corps  of  Engineers  (HQUSACE)  to  assess  the  potential  for  develop¬ 
ment  of  building  automation  system  (BAS)  specifications  (for  heating, 
ventilating,  and  air  conditioning  systems,  etc.)  based  on  the 
ANSI/ASHRAE  135-2004  -  the  BACnet®  communications  protocol  (here¬ 
after  ASHRAE  135  or  BACnet).  BACnet  enjoys  wide  industry  support;  a 
number  of  vendors  offer  related  products  and  services,  the  Navy  uses  the 
protocol,  and  a  limited  but  growing  number  of  Army  installations  also  use 
BACnet.  However,  there  is  apparently  no  BAS  specification  that  imple¬ 
ments  the  BACnet  protocol  in  an  Open  system,  where  an  Open  system  is 
defined  here  as  “One  (integrated,  multi-vendor)  system  with  no  future  de¬ 
pendence  on  any  one  contractor.”* 

The  BACnet  protocol  is  detailed  and  includes  comprehensive  require¬ 
ments,  but  also  provides  options  in  how  individual  vendors  might  choose 
to  implement  it.  However,  it  does  not  include  requirements  for  other  nec¬ 
essary  aspects  of  an  Open  BAS.  Such  vendor-specific  choices  or  lack  of  re¬ 
quirements  can  effectively  close  the  system  to  future  open  bid  procure¬ 
ments  (or  result  in  incompatible  systems)  if  not  adequately  addressed.  For 
example,  many  BACnet  applications  make  use  of  and  encourage  proprie¬ 
tary  objects  which  may  result  in  incompatible  systems.  Similarly,  BACnet 
does  not  specify  a  standard  for  a  “network  database”  thus  necessitating  the 
use  and  maintenance  of  multiple  configuration  tools  (from  multiple  manu¬ 
facturers),  and  in  some  cases  the  use  of  multiple  tools  to  replace  a  single 
device. 

Implementing  BACnet  in  an  open  manner  will  require  extensive  prescrip¬ 
tive  requirements  (particularly  in  regard  to  BACnet  “objects”  and  “proper¬ 
ties”)  and,  where  defining  prescriptive  requirements  is  impractical  or  im¬ 
possible,  optional  BACnet  functionality  selected  by  the  Contractor  will 
need  to  be  documented  via  submittal.  Overall  a  significant  amount  of  de¬ 
sign  and  contract  documentation  will  be  required. 


*  Meaning  no  future  dependence  on  either  the  specific  installing  controls  contractor  or  the  manufacturer 
of  the  controls. 
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The  primary  objective  of  this  project  was  to  evaluate  the  feasibility  of  cre¬ 
ating  an  Open  BAS  specification  based  on  BACnet  and  its  associated  tech¬ 
nology— not  to  compare  the  BACnet  protocol  with  the  ANSI  709.1  commu¬ 
nications  protocol  Since  the  Government  already  has  Open  BAS 
specifications  based  on  ANSI  709.1  (and  its  associated  technologies  usually 
referred  to  as  LonWorks®),  it  must  be  careful  to  continue  to  advance  its 
open  systems  goals. 

This  work  concludes  that,  while  it  is  possible  to  write  “Open-enough” 
BACnet-based  BAS  specifications,  the  effort  will  be  challenging  and  pre¬ 
scriptive,  and  will  require  a  greater  level  of  enforcement  than  an  equiva¬ 
lent  ANSI-709.1  (LonWorks)  based  specification.  The  resulting  system 
will  not  integrate  as  tightly  or  be  as  user  friendly  to  installation  operations 
and  maintenance  staff  as  a  LonWorks  system  based  on  the  existing  Uni¬ 
fied  Facility  Guide  Specification  [UFGS])  due  mainly  to  the  need  for  mul¬ 
tiple  configuration  tools  and  issues  in  establishing  and  maintaining  device 
communications. 

The  Navy  intends  to  publish  a  “Navy”  BACnet  BAS  specification  in  the  sec¬ 
ond  quarter  of  FY07.  While  this  assessment  concludes  that  a  sufficiently 
open  BACnet-based  BAS  specification  is  possible,  the  authors  do  not  be¬ 
lieve  the  Navy  specification  achieves  this  goal,  and  do  not  endorse  the 
Navy  specification.  The  Corps  intends  to  continue  to  work  with  the  Navy 
towards  a  unified  specification.  This  work  addresses  outstanding  technical 
issues/concerns,  this  involves  developing  a  two-spec  (front-end  and  build¬ 
ing  level  system)  approach  vis-a-vis  the  Navy’s  current  single  specification. 
It  also  involves  incorporating  control  sequences  and  developing  BACnet 
Points  Schedules  along  with  other  control  system  drawings.  It  also  in¬ 
cludes  developing  a  source  selection  procurement  methodology  that  pre¬ 
qualifies  BACnet  contractors. 

Development  of  unified  BACnet-based  BAS  specifications  should  proceed 
in  close  cooperation  with  the  Navy  and  Air  Force.  CERL  will  continue  to 
meet  with  the  Navy  on  a  periodic  basis  to  proceed  to  develop  these  specifi¬ 
cations  and  related  criteria.  Existing  LonWorks  specifications  and  Unified 
Facilities  Criteria  (UFC)  will  then  need  to  be  edited  to  ensure  consistency 
(not  be  repetitive)  with  the  new  BACnet  BAS  criteria,  primarily  in  regard 
to  common  or  overlapping  content  such  as  control  sequences  and  hard¬ 
ware  specifications). 
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1  Introduction 

1.1  Background 

For  years,  government  installations  (and  other  campus-like  facilities)  have 
faced  the  complexities  of  multi-vendor  building  automation  systems 
(BAS),  where  a  BAS  (for  the  purposes  of  this  report)  includes  local  build¬ 
ing-level  direct  digital  control  (DDC)  systems  along  with  the  hardware  and 
software  needed  to  integrate  building  level  systems  at  a  supervisory  level 
as  part  of  a  multi-building  campus  or  base-wide  system. 

Proprietary  BAS  hardware,  software,  and  communications  protocols  pre¬ 
sent  design,  installation,  and  operation/maintenance  challenges.  Adopting 
a  standard  communications  protocol  can  help  to  overcome  some  of  these 
challenges  by  permitting  different  vendors’  building-level  DDC  systems  to 
interoperate  by  communicating  among  themselves  and  with  one  or  more 
computer  workstations  and/or  servers.  In  practice,  this  consists  of  the 
open  exchange  of  data/information  between  DDC  systems  and  with  super¬ 
visory  system(s).  This  is  particularly  important  as  new  devices  and  systems 
are  added  to  an  existing  system  and  provides  benefits  at  both  the  base¬ 
wide  (campus-like)  supervisory  level  and  at  the  sub-system/building  level. 

There  is  a  great  need  to  identity  and  assess  design  and  specification  re¬ 
quirements  for  Open  building  automation  systems.  Headquarters,  U.S. 
Army  Corps  of  Engineers  (HQUSACE)  tasked  the  Engineer  Research  and 
Development  Center,  Construction  Engineering  Research  Laboratory 
(ERDC-CERL)  to  assess  the  potential  for  development  of  a  BAS  specifica¬ 
tion  (for  heating,  ventilating,  and  air  conditioning  systems  [HVAC],  etc.) 
based  on  the  BACnet  communications  protocol. 


NOTE:  This  report  uses  the  term  “BACnet”  to  refer  to  the  actual  BACnet  pro¬ 
tocol  as  well  as  to  mean  that  protocol  along  with  related  technologies.  While 
every  attempt  has  been  made  to  distinguish  which  meaning  is  intended,  in 
some  cases  the  reader  must  make  the  determination  from  context. 


*  For  the  purposes  of  this  document,  a  proprietary  system  is  defined  as  “a  system  where  sole  source 
procurement  is  required  for  system  modifications  or  expansions." 
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1.2  Objective 

The  specific  objective  of  this  work  was  to  identify  and  assess  design  and 
specification  requirements  for  Open  building  automation  systems  based 
on  ASHRAE  135. 

1.3  Approach 

To  complete  this  assessment,  the  project  team: 

1.  met  with  multiple  BACnet  manufacturers*  including;  Alerton,  Auto¬ 
mated  Logic,  Cimetrics,  Delta  Controls,  Siemens,  and  Trane 

2.  met  with  the  BACnet  Manufacturers  Association  (BMA),+  and  BACnet 
Testing  Laboratories  (BTL) 

3.  reviewed  a  draft  Navy  controls  specification  based  on  BACnet 

4.  met  with  Navy  representatives,  BACnet  consultants,  end  users  (Ohio 
State  University,  University  of  Cincinnati),  and  BACnet  International 

5.  met  with  Navy  representatives  and  BACnet  consultants 

6.  submitted  two  sets  of  (e-mail)  surveys  to  industry  and  BMA/BI  repre¬ 
sentatives,  and  reviewed  and  analyzed  their  responses 

7.  met  at  HQUSACE  with  Navy  representatives 

8.  analyzed  the  input  from  these  many  sources  to  identify  and  assess  de¬ 
sign  and  specification  requirements  for  an  Open  BAS  that  will  best 
serve  the  needs  of  the  user  community. 

1.4  Scope 

This  work  includes  an  assessment  of  the  feasibility  of  creating  an  Open 
BAS  specification  using  the  BACnet  protocol.  It  identifies  issues  and  ac¬ 
tions  required  to  address  those  issues  to  develop  criteria  for  Open  BACnet- 
based  BAS  systems.  The  intent  is  that  the  resultant  criteria  will  be  tri¬ 
service  (i.e.,  adopted  by  the  Army,  Navy,  and  Air  Force). 

This  assessment  goes  beyond  simply  identifying  BACnet-based  BAS  guide 
specification  requirements.  It  includes  an  investigation  of  BAS  require¬ 
ments  that  meet  the  goals  of  an  Open  system,  defined  here  as  “One  (inte¬ 
grated,  multi-vendor)  system  with  no  future  dependence  on  any  one  con¬ 
tractor.”  Although  this  work  emphasizes  HVAC  and  central 


*  Manufacturers  who  implement  ASHRAE  135  in  their  products, 
t  BMA  has  since  merged  into  BACnet  International  (Bl). 
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heating/cooling  plants,  it  is  not  intended  to  exclude  other  mechanical, 
electrical,  and  utility  systems. 

While  this  work  focused  on  identifying  open  systems  criteria  based  on  the 
use  of  the  BACnet  protocol  comparisons  were  made  between  BACnet-  and 
LoNWoRKS-based  systems  to  illustrate  Open  systems  concepts  and  related 
specification  requirements. 

1.5  Mode  of  Technology  Transfer 

This  report  will  be  made  accessible  through  the  World  Wide  Web  (WWW) 
at  URL:  http://www.cecer.army.mil 
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2  Developing  a  BAS  Specification 

2.1  Early  BAS  Development 

At  the  supervisory  level,  the  purpose  of  the  BAS  is  to  perform  overall  su¬ 
pervisory  management,  monitoring,  and  certain  control  functions.  These 
functions  might  include  remote  alarm  reporting,  remote  scheduling 
(on/off  control),  trending  and  trend  reports,  load  shedding/load  manage¬ 
ment,  remote  setpoint  adjustment,  initial  diagnosis  of  a  service  call  and 
other  maintenance  management  functions,  load  and  utility  monitoring/ 
measurement  for  the  purpose  of  performance  monitoring  and  reporting. 
At  the  building  or  sub-system  level,  the  goal  is  to  support  interoperability 
with  the  base-wide/supervisory  system  while  also  communicating  and 
sharing  building-specific  operational  data  such  as  on/off  scheduling  com¬ 
mands,  setpoints,  and  outside  air  temperature. 

With  help  from  several  other  agencies  and  industry,  the  U.S.  Army  Corps 
of  Engineers  began  developing  specifications  based  on  LonWorks  tech¬ 
nology  in  2001.  That  effort  resulted  in  Unified  Facilities  Guide  Specifica¬ 
tions  (UFGS)  13801  and  15951  (also  referred  to  as  UFGS  25  10  10  and 
UFGS  23  09  23,  respectively),  which  have  been  adopted  for  use  by  the 
Army,  Navy,  and  Air  Force.  These  specifications  are  available  through  the 
Corps  of  Engineers’  Techlnfo  website  or  the  Whole  Building  Design  Guide 
(“Construction  Criteria  Database”)  website,  which  are  accessible  through 
URLs: 


http://www.hnd.usace.armv.mil/techinfo/enqpubs.htm 

http://www.wbdq.orq/ccb/ 

Draft  Unified  Facilities  Criteria  (UFC)  are  available  through  URL: 
https://kd.erdc.usace.army.mil/proiects/besc/ufc/ 

BACnet  is  a  standard  communications  protocol  for  building  automation 
systems  that  enjoys  wide  industry  support;  a  number  of  vendors  offer 
products  and  services  based  on  it,  the  Navy  uses  the  protocol,  and  a  lim¬ 
ited  number  of  Army  installations  also  use  BACnet.  Its  use  will  likely  con¬ 
tinued  to  grow.  The  Navy  and  GSA  (among  others)  have  developed  BAS 
specifications  for  the  implementation  of  the  BACnet  protocol.  The  Navy 
specifiation  is  in  draft  form  and  CERL  has  been  working  with  the  Navy  to 
identify  the  needs  and  requirements  for  unified  (multi-service)  BACnet 
BAS  specifications  in  coordination  with  the  Air  Force. 
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2.2  The  Future  of  BAS  Specifications 

The  Corps  will  be  de-emphasizing  the  use  of  UFGSs  in  favor  of  the  Military 
Construction  (MILCON)  design/build  request  for  proposal  (RFP)  on  a  ma¬ 
jority  of  projects.  However,  the  Navy  design/build  approach  uses  “specs” 
for  both  controls,  and  for  HVAC  test,  adjust,  and  balance  (TAB)  require¬ 
ments.  This  is  the  same  approach  that  was  advocated  by  many  within  the 
Corps  for  our  MILCON  RFP,  but  to  no  avail.  There  are  also  a  substantial 
number  of  controls  retrofit  projects  funded  by  means  other  than  MILCON 
that  require  specifications  and  where  it  is  assumed  that  non-proprietary 
(open)  systems  should/will  be  procured  thus  suggesting  an  ongoing  need 
for  UFGSs. 

2.3  The  Open  System  Goal 

Early  in  this  effort,  CERL  defined  a  baseline  goal  and  related  sub-goals  to 
help  define  Open  System  needs  and  subsequent  requirements.  Some  of 
these  goals  may  not  be  achievable  in  the  near  term.  At  this  point,  it  may  be 
best  to  trade  “bells  and  whistles”  and  sophisticated  sequences  for  a  less 
complicated,  more  open  system,  e.g.,  accept  a  simpler  economizer  to  get  a 
configurable  application-specific  controller  instead  of  a  programmable 
controller.  The  resulting  central  focus  of  this  work  was  to  obtain  an  Open 
system  characterized  by: 

1.  One  system.  Multiple  buildings  with  controls  installed  by  multiple 
vendors  are  integrated  into  one  system. 

2.  One  common  front-end  that  provides  users  with  the  capability  to  inter¬ 
face  with  all  buildings  (monitoring,  supervisory  control,  etc.). 

3.  One  common  tool  for  network  management.  For  manage¬ 
ment/configuration.  One  common  tool  for  device  configuration. 

4.  No  future  need  for  the  original  (installing)  contractor.  Additions, 
modifications,  and  retrofits  can  be  easily  (without  significant  addi¬ 
tional  cost)  made  to  the  system  without  dependence  on  the  original 
contractor  nor  require  substantial  engineering  or  other  technical  de¬ 
velopment. 

The  effort  to  obtain  an  Open  system  must: 

1.  Minimize  the  number  of  software  interface  packages 

2.  Provide  one  interface  for  monitoring 

3.  Provide  one  interface  for  device/system  management/configuration 

4.  (Optimally)  provide  one  interface  for  device  programming 

5.  Allow  no  Gateways.  The  following  should  be  permitted  only  as  excep¬ 
tions: 


ERDC/CERL  TR-07-3 


6 


a.  A  supervisory  interface  to  legacy  systems 

b.  Specialized  applications.  It  may  be  necessary  to  define  specialized 
applications  such  as  fume  hood  monitoring,  and  cases  where  a  sin¬ 
gle  packaged  unit,  single  chiller,  or  single  boiler,  etc.  may  need  to  be 
connected  to  the  control  network,  but  the  manufacturer’s  packaged 
controller  is  not  Open  Systems  compatible. 

6.  Allow  no  use  of  “jellynet”  (i.e.,  the  use  of  some  proprietary  communica¬ 
tion  between  different  “islands”  of  openness).  This  is  closely  related  to 
the  stipulation  to  “allow  no  Gateways.” 

7.  Provide  device  interchangeability.  Must  be  able  to  remove  a  device 
from  one  manufacturer  and,  without  adding  any  other  networking 
hardware,  replace  it  with  a  device  from  another  manufacturer. 

8.  Create  a  system  that  DOES  work  together,  not  one  that  CAN  work  to¬ 
gether. 

9.  Limit  the  number  of  options.  More  options  generally  equates  to  more 
ways  to  close  the  system. 

10.  Provide  good  system  documentation.  The  system  must  be  documented 
so  that  future  contractors  or  the  Government  can  understand  what  has 
been  done. 

11.  Use  industry  standards  where  possible,  but  be  willing  to  extend  them 
by  specifying  in  a  prescriptive  manner  exactly  how  to  do  things  that  are 
not  done  in  a  standard  way. 

12.  Be  performance-based  when  possible,  but  be  prescriptive  where 
needed  to  ensure  interoperability.  (Experience  with  LonWorks  indi¬ 
cates  that,  to  get  an  open  system,  it  will  be  necessary  to  be  prescriptive 
about  nearly  all  issues  related  to  communication  between  devices) 

2.4  Number  of  Specifications 

Minimally,  in  addition  to  a  building-level  BACnet  BAS  specification,  a 
BACnet-based  system  integration  specification  is  needed  to  specify  front- 
end/supervisory,  building -to-building  networking,  and  network  manage¬ 
ment.  This  will  be  similar  to  the  LonWorks  Utility  Monitoring  Control 
System  (UMCS)  UFGS-13801.  In  the  extreme  case  as  many  as  eight  (but 
more  likely  only  four  or  five)  specifications  could  be  needed  to  accommo¬ 
date  both  BACnet  and  LonWorks. 

The  issue  here  is  how  best  to  package  the  specifications  to  ensure  practical 
application  of  the  criteria  including  ease  of  use,  specification  maintenance, 
and  integration  with  other  specifications.  There  are  presently  two 
LonWorks  specifications.  The  Navy  originally  suggested  the  need  to  inves¬ 
tigate  coordination  between  the  LonWorks  and  BACnet  BAS  specifica- 
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tions  as  part  of  a  BACnet  BAS  specification  development  effort.  Eight  fun¬ 
damentally  different  topics  must  be  addressed  (conceivably  through  sepa¬ 
rate  specifications): 

1.  Hardware.  Sensors,  valves,  dampers,  actuators,  wire  and  cabling,  en¬ 
closures,  and  other  miscellaneous  hardware.  These  things  are  (largely) 
protocol  and  vendor  independent,  e.g.,  a  Johnson  Controls  valve  can 
work  fine  on  a  Honeywell  system.  This  might  even  include  common 
DDC  hardware  requirements  that  are  protocol  independent  (e.g.,  the 
requirement  that  the  controller  not  loose  its  program  in  case  of  a  power 
failure).  As  a  result,  it  will  be  wise  to  consider  using  the  same  Hard¬ 
ware  requirements  in  both  the  LonWorks  and  BACnet  specifications. 

2.  Building -lev el  system  performance  verification  test  (PVT),  Training, 
and  other  execution  items.  Again,  these  elements  are  largely  protocol 
and  vendor  independent  (although  some  requirements/submittals  may 
be  unique  to  LonWorks  or  BACnet). 

3.  Control  Sequences.  Sequences  should  be  protocol  and  vendor  inde¬ 
pendent. 

4.  LonWorks  requirements  inside  the  building.  This  will  cover  network 
requirements,  protocol  specific  issues,  and  DDC  hardware  require¬ 
ments  unique  to  LonWorks  systems.  This  will  be  a  subset  of  the  exist¬ 
ing  UFGS-15951. 

5.  BACnet  requirements  inside  the  building.  This  will  cover  network  re¬ 
quirements,  protocol  specific  issues,  and  DDC  hardware  requirements 
unique  to  BACnet  systems. 

6.  UMCS  Workstation  requirements.  This  will  cover  protocol  independ¬ 
ent  requirements  of  a  base-wide  (or,  multi-vendor  integrated)  system. 
This  would  include  computer  hardware  requirements  and  installation, 
as  well  as  any  IP  network  requirements  common  to  either  LonWorks 
or  BACnet.  It  could  include  sections  on  M&C  functionality  (such  as 
demand  limiting),  graphical  user  interface  (GUI)  requirements,  ac¬ 
cess/authentication  requirements,  and  optionally  requirements  for 
web-based  GUIs.  It  would  also  include  PVT,  training,  and  possibly 
submittals  as  well. 

7.  LonWorks  requirements  outside  the  building  as  part  of  a  base-wide 
(or,  multi-vendor  integrated)  system.  This  would  cover  system  inte¬ 
gration  and  Monitoring  and  Control  (M&C)  software/hardware  re¬ 
quirements  unique  to  LonWorks  systems  (e.g.,  the  requirement  to  use 
an  LonWorks®  Network  Services  (LNS)  database). 

8.  BACnet  requirements  outside  the  building  on  the  base-wide  (or,  multi¬ 
vendor  integrated)  system.  This  would  cover  system  integration  and 
M&C  requirements  unique  to  BACnet  systems. 
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Clearly,  it  is  not  desirable  to  have  eight  specifications.  On  the  other  hand, 
to  ensure  that  any  building  can  communicate  openly  with  a  UMCS,  it  is 
desirable  to  keep  the  UMCS  contractor  at  “arms  length”  from  the  building 
contractor.  This  suggests  a  separation  of  building-level  specifications  from 
UMCS-level  specifications. 

Another  factor  to  consider  is  the  desire  to  avoid  repetition.  If,  for  example, 
a  temperature  sensor  is  specified  in  three  different  places  in  three  different 
specifications,  then  any  later  change  necessitates  changing  the  specifica¬ 
tion  in  three  places.  This  invites  inconsistency  in  the  future  when  different 
sections  of  the  specifications  have  different  requirements  for  identical 
hardware.  For  this  reason,  it  might  be  desirable  to  have  all  the  common 
(protocol  independent)  requirements  in  a  separate  document.  For  exam¬ 
ple,  the  hardware  requirements  (#1),  building-level  execution  (#2)  and 
control  sequences  (#3)  could  be  combined  into  one  specification.  The  pro¬ 
tocol-dependent  portions  might  be  better  located  in  a  division  17  or  the 
new  division  25  (Integrated  Automation)  specification. 

Finally,  there  is  a  packaging  issue:  contractors  do  not  want  to  be  given  a 
large  number  of  specifications  that  are  irrelevant  to  the  job,  nor  do  they 
want  to  have  related  specifications  scattered  out  among  multiple  docu¬ 
ments.  The  better  the  guide  specification  breakout  matches  the  contractor 
requirements,  the  easier  the  designer’s  job  will  be.  Consequently,  this  sim¬ 
plified  approach  recommends  five  specifications: 

1.  HVAC  controls  specification:  includes  elements  1,  2,  and  3 

2.  LonWorks  building  specification  (UFGS  15951):  element  4  above 

3.  LonWorks  UMCS  specification  (UFGS  13801):  elements  6  and  7 

4.  BACnet  building  specification:  element  5  above 

5.  BACnet  UMCS  specification:  elements  6  and  8. 

This  separation  of  specifications  helps  to  ensure  that  any  building  installed 
under  the  building  specification  can  be  integrated  under  the  UMCS  speci¬ 
fication.  This  is  because  the  building  contractor  has  no  guidance  on  what  is 
to  be  done  at  the  UMCS  level  other  than  what  is  in  the  building  specifica¬ 
tion  -  there  is  less  potential  for  the  contractor  to  close  the  system. 

There  is  general  agreement,  primarily  with  the  Navy,  that  separate  specifi¬ 
cations  are  needed.  Existing  UFGS-13801  and  15951  will  need  to  be  edited 
to  relocate  portions  to  a  new  HVAC  Controls  Specification  and  two  BACnet 
UFGSs  will  need  to  be  developed. 
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3  Required  Level  of  Detail 

3.1  Issue  Categories 

BACnet-related  BAS  specification  issues  are  categorized  here  based  on  the 
follow-up  necessary  for  criteria  development,  as  an: 

1.  Open  issue:  an  issue  requiring  additional  investigation  prior  to  con¬ 
cluding  its  impact  on  or  necessity  of  being  addressed  in  the  specifica¬ 
tions  or  design  guidance  (UFC), 

2.  Resolved  issue:  an  issue  which  has  been  the  overall  impact  on  the 
specification  has  been  determined  to  be  substantial  and  which  requires 
significant  effort  to  address  in  the  specificifi cation. 

3.  Closed  issue:  an  issue  that  either  has  little  to  no  bearing  on  the  crea¬ 
tion  of  a  specifications  or  that  requires  minimal  effort  to  address  in  the 
specification.  These  issues  are  included  here  for  completeness. 

3.2  BACnet  BAS  Guide  Specifications 

While  the  designer  need  not  be  intimately  familiar  with  the  intricacies  of 
BACnet  (such  as  PICS,  BIBBS,  Objects,  Properties,  Services,  etc.),  some 
level  of  understanding  is  required  for  designer  selections  and  subsequent 
field-level  implementation/verifi cation  of  specified  system.  The  intent  of 
writing  BACnet  BAS  guide  specifications  is  to  pre-assess  and  pre-define 
key  open  system  requirements  so  as  to  minimize  the  time  and  effort  re¬ 
quired  on  the  part  of  the  designer  and  to  potentially  assist  those  who  are 
responsible  for  accepting  the  installed  system.  There  are  a  number  of  de¬ 
tails  related  to  these  elements  that,  left  unspecified,  can  result  in  proprie¬ 
tary  and  or  non-interoperable  multi-vendor  systems. 

The  BACnet  protocol  is  very  functional  and  flexible,  but  complex  in  part 
due  to  its  many  options  (such  as  protocol  options  and  media  types).  While 
these  options  are  described  in  more  detail  below,  it  will  be  necessary  to  re¬ 
strict  options  to  get  openness  and  interoperability  as  this  helps  to  ensure 
compatibility  between  pre-existing  systems  and  those  procured  later.  In 
addition  there  are  some  requirements  of  an  Open  system  not  covered  by 
the  BACnet  protocol  that  must  be  addressed  in  a  BACnet-based  BAS  speci¬ 
fication.  A  performance-based  specification  alone  will  not  work  due  to  the 
absence  of  a  means  to  verify  third  party  interoperability  (as  is  the  case  with 
how  Government  procurement  contracts  are  issued).  This  is  further  ad¬ 
dressed  under  in  the  “Contracting  Issues/Approaches“  section  (p  25).  Suf- 
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fice  it  to  say  that  even  a  performance-based  specification  would  need  to 
define  how  to  implement  the  various  options  in  BACnet  so  as  to  provide  a 
level  playing  field  for  contract  bidders,  which  brings  us  back  to  the  need 
for  detailed  requirements.  Therefore  it  is  desirable  to  be  performance 
based  and  use  industry  standards  when  possible,  but  also  to  extend  those 
standards  and  be  prescriptive  as  necessary. 

For  many  of  the  following  issues,  there  is  a  concern  that  BACnet  is  not 
prescriptive  enough.  In  these  cases  there  is  usually  an  obvious,  simple  way 
to  extend  the  specification  to  ensure  openness,  but  the  problem  is  that 
these  extensions  can  potentially  be  too  restrictive  and  thus  limit  competi¬ 
tion  because  some  or  many  vendors  may  not  be  able  to  meet  the  restric¬ 
tions/requirements.  The  challenge,  then,  is  to  find  the  appropriate  balance 
between  ASHRAE  135,  a  “blanket”  prescriptive  clause,  and  a  (possibly) 
painful  detailed  mix  of  performance  based  and  prescriptive  requirements. 

This  issue  is  resolved;  a  great  deal  of  detail  is  needed,  but  the  actual  de¬ 
tails  required  in  the  specifications  still  need  to  be  determined. 

3.3  Objects 

3.3.1  BACnet  Proprietary  Objects 

BACnet  defines  Proprietary  Objects  as  those  having  a  type  value  outside 
the  range  o  to  128.  While  BACnet  defines  a  number  of  standard  objects 
and  their  underlying  properties,  it  also  permits  the  use  of  proprietary  ob¬ 
jects.  This  allows  information  that  does  not  fit  into  standard  objects  to  be 
made  accessible  via  BACnet  events  and  services,  which  can  be  a  very  good 
thing.  However,  because  they  are  unique  to  that  vendor,  proprietary  ob¬ 
jects  present  a  concern  in  that  other  devices/systems  may  not  be  able  to 
interoperate  with  these  objects.  In  the  extreme  case,  proprietary  objects 
can  potentially  close  a  system.  To  help  ensure  interoperability,  the  specifi¬ 
cations  should  require  Contractors  to  provide  interoperability  details  for 
Proprietary  Objects.  This  might  best  be  accomplished  by  requiring  that 
this  detail  be  shown  in  a  “Points  Schedule”  drawing  submitted  by  the  Con¬ 
tractor. 

This  issue  is  resolved;  proprietary  objects  need  to  be  addressed  in  the 
specifications  and  the  requirements  for  their  use  need  to  be  defined  and 
coordinated  with  industry  as  part  of  the  specification  development  proc¬ 


ess. 
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3.3.2  Inappropriate  Property  Usage 

Object  properties  can  potentially  be  used  inappropriately.  For  example  the 
analog  input  Min_Present_Value  might  be  used  to  communicate 
data/information  “other”  than  the  minimum  present  value.  While  this  is 
not  common  practice,  it  remains  a  concern.  The  representation  of  the 
same  information  in  different  object  types  and  properties  is  a  greater  con¬ 
cern.  For  instance,  analog  values  (AV)  can  be  mapped  as  a  binary  value 
(BV). 

This  issue  is  closed;  a  simple  requirement  will  be  included  in  the  specifi¬ 
cations:  “Properties  shall  not  be  used  for  other  than  their  intended  use  as 
defined  in  ASHRAE  135.” 

3.3.3  BIBBS  /  PICS  and  Points  Schedule  Drawings 

To  help  facilitate  interoperability,  ASHRAE  135  describes  BACnet  Interop¬ 
erability  Building  Blocks  (BIBBs)  and  device  profiles,  and  vendors  docu¬ 
ment  compliance  through  Protocol  Implementation  Conformance  State¬ 
ment  (PICS)  data  sheets  for  their  devices.  Neither  appears  to  be  sufficient 
to  define  interoperability  requirements  because  needed  properties  in  a 
given  device  may  not  be  documented  in  either  the  BIBBs  or  PICS.  Neither 
contains  a  sufficient  level  of  detail  or  thoroughness  to  ensure  that  a  device 
meets  interoperability  requirements. 

For  example,  ASHRAE  135  permits  a  vendor  to  indicate  that  their  control¬ 
ler  supports  the  BACnet  object  “Analog  Input”  and  that  their  “Analog  In¬ 
put”  object  supports  the  write  property  without  requiring  every  analog  in¬ 
put  on  the  controller  to  meet  the  requirements  of  a  BACnet  “Analog  Input” 
object  and  without  requiring  every  BACnet  “Analog  Input”  object  on  the 
controller  to  support  the  write  property.  BACnet  only  requires  that  at  least 
one  analog  input  be  a  BACnet  Analog  Input  object  and  that  at  least  one  of 
those  Analog  Input  objects  support  the  write  property.  This  is  less  than 
satisfying  particularly  when  desired  functionality  that  the  Government 
may  expect  (and  pay  for)  may  or  may  not  be  provided.  In  contrast, 
LonWorks  criteria  addressed  this  by  showing  this  type  of  expected  func¬ 
tionality  in  a  Points  Schedule  drawing. 

To  resolve  this,  the  specification  could  potentially  include  a  blanket  state¬ 
ment  such  as;  “all  AI  objects  shall  support  xxx  optional  property.”  This  is 
probably  not  practical  primary  because  it  would  restrict  the  number  of 
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vendors  who  can  meet  this  requirement  and  would  be  overkill  resulting  in 
unneeded  functionality  in  some  applications. 

Alternatively,  in  theory,  the  specification  could  require  that  all  BACnet  Ob¬ 
ject  Types  support  BACnet  required  properties  along  with  a  list  of  BACnet 
optional  properties.  For  example,  the  spec  could  require  that  “all  analog 
inputs  shall  be  BACnet  Analog  Input  Object  Types  and  shall  support  the 
optional  COV_Increment  property.”  Based  on  our  discussions  with  and 
survey  of  industry,  a  number  of  vendors  would  not  be  able  to  meet  this  re¬ 
quirement  either. 

Instead,  a  more  practical  approach  seems  to  be  where  the  designer  shows 
what  objects  AND  properties  each  device  will  support  in  specific  applica¬ 
tions.  Given  a  sequence  of  control  for  a  specific  application  and  its  associ¬ 
ated  input/output  points  list,  CERL  intends  to  develop  specific  require¬ 
ments  for  specific  points  on  a  device.  It  seems  essential  to  present/show 
this  in  the  form  of  a  Points  Schedule  drawing.  For  each  of  the  points,  re¬ 
quirements  for  support  of  BACnet  services,  objects,  and  object  properties 
need  to  be  developed.  For  example,  for  a  given  air  handler,  Return  Air 
Temperature  (RA-T)  might  be  shown  as  an  Analog  Input  (AI)  BACnet  ob¬ 
ject  with  the  following  properties:  Description  (read/writeable)  and  COV 
Increment  (read/writeable).  At  the  same  time  it  may  not  be  practical  to 
show  all  object  properties  on  a  drawing  because  objects  can  include  a  large 
number  of  properties  (both  optional  and  required). 

This  issue  is  open.  While  it  appears  object  and  property  detail  is  needed  it 
is  not  clear  how  much  can/should  be  addressed  via  specification  and  how 
much  needs  to  be  shown  in  a  Points  Schedule  drawing.  Points  Schedules 
for  several  example  applications  need  to  be  developed  to  make  a  determi¬ 
nation. 

3.3.4  Overrides 

In  support  of  fundamental  functionality,  it  will  be  necessary  that  the  BAS 
have  the  capability  to  perform  overrides  of  setpoints  and  device  outputs. 
There  are  several  ways  of  accomplishing  overrides,  some  proprietary.  AIs 
and  Bis  require  that  they  be  taken  out  of  service  before  being  put  in  over¬ 
ride,  but  the  specification  likely  will  not  include  a  requirement  to  override 
AIs  and  Bis  because  this  functionality  is  over  and  above  that  considered  to 
be  fundamental. 
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Advanced  override  functionality  would  include  the  capability  to  (easily) 
determine  what  points  are  currently  in  an  override  status.  The  best  way  to 
perform  functions  such  as  finding  out  how  many  devices  are  in  override  is 
to  use  the  ReadPropertyConditional,  but  this  is  poorly  supported. 

This  issue  is  resolved;  it  must  still  be  determined  how  to  specify  over¬ 
rides  of  setpoints  and  device  outputs  as  well  as  the  viewing  and  managing 
of  overrides. 

3.3.5  (COV,  Intrinsic,  Algorithmic)  Event  Reporting 

To  transfer  data  between  devices,  it  seems  like  change  of  value  (COV) 
event  reporting  is  required.  However,  vendors  do  not  recommend  (i.e., 
they  oppose)  it  being  required.  Many  smaller  (low  level  of  functionality) 
devices  simply  do  not  have  the  functionality  and  memory  to  support  it.  In¬ 
trinsic  alarming  may  be  more  useful  for  alarming.  ReadProperty  is  the  un¬ 
derstood  fallback  to  COV.  This  is  an  informal  agreement  amongst  vendors 
where  if  a  controller/device  does  not  support/subscribe  to  COV  it  fall 
backs  to  polling  (ReadProperty).  COV  must  be  specified  such  that  if  the 
COV  subscription  fails  the  device  automatically  reverts  to  polling.  There  is 
some  uncertainty  regarding  how  and  what  values  to  specify  for  various 
subscriptions  to  services  such  as  COV  subscription  renewal  interval.  Initial 
concerns  were  that  algorithmic  reporting  might  be  used  to  close  systems. 
Our  discussions  with  industry  and  BACnet  experts  indicate  that  this  is  not 
the  case.  They  also  indicated  that  it  is  powerful  and  therefore  very  useful. 

This  issue  is  open.  The  capability  to  transfer  data  (such  as  an  alarm  condi¬ 
tion)  between  controllers  is  obviously  needed,  but  it  is  not  clear  if  it  should 
be  accomplished  by  polling  or  based  on  COV.  If  COV  is  the  preferred  ap¬ 
proach  it  must  also  be  determined  whether  COV  should  be  required  or  if 
controllers  should  attempt  COV,  but  revert  to  polling  if  COV  is  not  avail¬ 
able. 

3.4  Network  Management  and  Device  Configuration 

3.4.1  Central  Database 

This  is  a  critical  issue.  In  a  multi-vendor  system  certain  base-wide  supervi¬ 
sory  functions  such  as  alarm  handling  and  system  scheduling  (Occu- 
pied/Unoccupied/WarmUp-CoolDown)  should  be  managed  through  a 
single  vendor’s  system  or  a  single  software  package.  This  common  inter¬ 
face  should  also  provide  for  display  of  selected  monitored  points  ideally  to 
include  a  graphical  display.  With  LonWorks  technology  a  de-facto  data- 
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base  standard  exists  (LNS™)  and  the  LonWorks  -based  UFGS-13801  re¬ 
quires  the  use  of  LNS  resulting  in  a  centralized  or  standardized  database 
that  provides  for  3rd  party  access  to  the  control  system  network/devices. 
BACnet  neither  specifies  nor  requires  a  standard  database. 

In  a  BACnet  system,  vendors  create  their  own  proprietary  database(s). 

This  is  accomplished  using  a  tool  that  queries  the  network  to  obtain 
BACnet  device  data  (including  third  party  BACnet  device  data).  This  proc¬ 
ess  is  called  discovery  and  uses  the  “Who-Is”  and  “Who-Has”  service  re¬ 
quests  and  the  associated  responses  “I-am”  and  “I-Have.”  Discovery  relies 
on  the  ability  of  controllers  to  be  addressed  via  their  Device  ID  and  to  re¬ 
spond  to  a  “Who-Is”  query. 

Discovery  of  devices  and  their  associated  Objects  on  MS/TP  (the  most 
common  media  type)  network  are  problematic  because  a  Slave  device  on 
MS/TP  cannot  (by  BACnet  definition)  respond  to  the  “Who  Is”  query  and 
therefore  cannot  be  discovered  on  the  network.  In  particular,  a  BACnet 
Application  Specific  Controller  (B-ASC)  is  not  required  by  BACnet  to  have 
the  ability  to  become  a  Master  on  the  MS/TP  network  (and  thus  is  a  slave) 
and  may  not  be  able  to  be  discovered.  A  brute  force  method  exists  to  iden¬ 
tify/discover  slave  devices,  but  appears  to  be  inefficient  and  time  consum¬ 
ing. 

Part  of  our  concern  about  this  issue  stems  from  the  potential  situation 
where  the  government  wants  to  let  a  Contract  to  replace  existing  Vendor  A 
(or  renew  the  Vendor  A  contract).  If  Vendor  C  wants  to  bid  on  the  Con¬ 
tract,  vendor  C  is  at  a  competitive  disadvantage  if  the  system  contains 
slave  devices  known  only  to  Vendor  A. 

Specifying  the  use  of  a  proxy  device  is  a  possible  way  to  deal  with  discovery 
(where  a  master  device  serves  as  a  proxy  for  the  slave  device).  As  a  proxy, 
the  master  device  responds  to  a  “who-Is”  query  for  the  slave  device.  Re¬ 
quiring  detailed  submittal  documentation,  when  slave  devices  are  used,  is 
another  option  where  this  documentation  would  serve  to  facilitate  slave 
device  discovery. 

This  issue  is  open.  Prohibiting  the  use  of  slave  devices  could  potentially 
exclude  many  low-cost  BACnet  controllers,  and  industry  seems  opposed  to 
our  prohibiting  the  use  of  slave  devices.  The  possible  use  of  proxies  and/or 
detailed  documentation  needs  to  be  investigated. 
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3.4.2  System  Integration 

In  a  multi-vendor  system  these  different  vendors’  systems  (particularly  as 
part  of  separate  projects/contracts)  need  to  be  (readily)  integrated.  As  dis¬ 
cussed  under  “Number  of  Specifications44  (p  6)  and  “Contracting  Is¬ 
sues/Approaches44  (p  25)  sections,  system  integration  in  an  Army  installa¬ 
tion  environment  consists  of  integrating  building-level  systems  with  a 
single-vendor  front-end  (UMCS)  where  this  single-vendor  UMCS  (which 
may  include  multiple  client  workstations)  is  used  to  monitor/manage  all 
(multi-vendor)  building-level  systems  so  that  functions  such  as  device 
scheduling  (on/off),  energy  management,  and  other  related  actions  are 
performed  from  a  single  user  interface.  It  is  not  our  intent  to  procure  a 
new  front-end  with  every  newly  installed  building-level  system.  (This  ap¬ 
proach  is  not  unusual,  but  seemed  foreign  to  some.) 

The  following  two  questions  were  posed  to  BACent  consultants  and  to  in¬ 
dustry: 

Consider  a  situation  with  an  existing  “Vendor  A”  front-end  where  “Vendor 
B”  is  hired  to  install  a  building-level  DDC  system. 

1.  Will  “Vendor  B”  be  comfortable  providing  a  “working”  system  and 
walking  away  from  it  (turning  it  over  as  complete)  confident  that  is 
ready-to-be-integrated  to  the  “Vendor  A”  front-end? 

2.  Will  “Vendor  A”  be  comfortable  being  required  to  integrate  the  Vendor 
B  system  in  the  absence  of  Vendor  B? 

The  industry  responses  indicate  that  it  is  likely  that  vendor  cooperation  is 
required  although  with  adequate  documentation  cooperation  will  not  be 
required.  (Note  -  this  is  also  the  case  with  LonWorks  and  part  of  the  in¬ 
tent  of  the  Points  Schedules  specified  in  UFGS-13801  and  15951).  There¬ 
fore,  it  appears  there  are  no  technical  barriers,  but  a  BTL  listed  BACnet 
Operator  Workstation  (B-OWS)  may  help  ensure  that  integration  is  not  a 
problem.  This  listing  is  not  yet  available,  but  should  be  included  in  the 
specification  once  it  is. 

As  a  related  issue,  building-level  Contractors  can  be  expected  to  perform 
limited  integration  at  a  3rd  party  UMCS  front-end.  (i.e.,  where  “Vendor  B” 
works  on  the  “Vendor  A”  front-end).  For  example  Vendor  B  can  be  ex¬ 
pected  to  set  up  graphics  on  the  “Vendor  A”  front-end.  Still,  a  systems  in¬ 
tegration  contract  is  advisable  (as  is  the  case  with  the  LonWorks  UFGSs) 
where  “Vendor  A”  is  responsible  for  integration  of  building -level  systems 
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to  Vendor  A’s  front-end.  The  use  of  a  separate  integration  contract  is  in  the 
Governments  best  interest  because  the  SI  provides  a  quality  control  ser¬ 
vice  by  helping  to  ensure  that  that  building-level  contractor  provides  and 
meets  open  system  requirements. 

This  issue  is  resolved.  Appropriate  specification  requirements  (including 
documentation)  will  be  defined. 

3.4.3  Multiple  Configuration  Tools  for  Network  Communication  Settings 

The  ASHRAE  135  standard  does  not  specify  or  require  that  devices  expose 
all  network  communication  parameters  in  an  open,  standard  manner.  In¬ 
dustry  implementations  do  not  expose  this  information  in  a  standard 
manner,  which  means  that  use  of  multi-vendor  BACnet  will  require  the 
use  of  proprietary  configuration  tools  from  multiple  vendors.  This  is  in 
sharp  contrast  to  LonWorks,  where  the  use  of  a  single  network  configura¬ 
tion  tool  which  interacts  with  the  LNS  database  helps  to  reduce  the  need 
for  proprietary  tools  from  multiple  vendors. 

For  example,  a  VAV  box  may  have  a  Binary  Object  representing  its  occu¬ 
pancy  status  which  supports  a  ReadProperty  on  its  PresentValue  (the  VAV 
box  is  a  data  server  and  supports  the  BIBB  DS-RP-B).  Furthermore,  an 
AHU  controller  may  wish  to  read  that  occupancy  in  order  to  turn  itself  on 
as  needed  (the  AHU  controller  is  a  data  client  and  supports  DS-RP-A). 
While  the  VAV  box  does  not  need  to  know  which  device  is  reading  its  data, 
the  AHU  needs  to  know  where  to  read  the  data  from.  The  AHU  controller 
must  contain  the  device  ID,  object  ID,  and  property  ID  of  the  VAV  box's 
occupancy  present  value.  ASHRAE  135  does  not  require  that  this  informa¬ 
tion  be  exposed  on  the  network. 

While  this  means  that  installation  of  a  new  device  containing  network  ad¬ 
dresses  for  remote  devices  will  require  the  use  of  a  vendor-specific  con¬ 
figuration  tool,  the  issue  becomes  even  worse  when  controller  replacement 
within  a  building  is  contemplated.  In  this  case,  not  only  the  replaced  de¬ 
vice,  but  other  devices  will  probably  need  to  be  reconfigured  as  well  using 
their  vendor-specific  configuration  tools.  In  the  example  of  a  VAV  box  and 
the  AHU  controller,  replacement  of  the  VAV  box  will  likely  require*  that 

*  *  If  you  replace  a  device  and  use  the  same  identifiers  (Device/Object/Property  identifiers)  then  the 
bindings  in  the  client  device  will  still  work  and  networkcommunication  will  be  maintained.  However, 
ASHRAE  135  does  not  require  that  Device/Object/Property  identifiers  be  field  assignable,  and  this  is 
not  well  supported  by  industry.  Another  possibility  is  to  reinitiate  the  binding,  if  the  device  supports  dy- 

(footnote  continued  on  next  page) 
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the  network  configuration  information  in  the  AHU  controller  be  changed 
to  point  to  the  new  Device/Object/Property  in  the  new  VAV  box  controller. 
If  the  VAV  controller  is  from  a  different  manufacturer  than  the  AHU  con¬ 
troller,  the  VAV  installer  be  required  to  use  the  proprietary  tool  belonging 
to  the  AHU  controller  manufacturer.  Furthermore,  lack  of  a  central  data¬ 
base  of  network  bindings  makes  it  difficult  to  even  know  what  other  de¬ 
vices  (bindings)  need  to  be  updated;  there  is  no  way  to  query  the  network 
(or  a  database)  to  determine  which  controllers  talk  to  which. 

One  industry  expert  suggested  requiring  network  communication  parame¬ 
ters  be  settable  via  Writeable  properties  of  (presumably  proprietary) 
BACnet  Objects.  A  Graphical  User  Interface  (GUI)  could  then  be  devel¬ 
oped  to  serve  as  a  network  configuration  tool  for  these  properties.  This 
GUI  would  serve  as  a  common/single  network  configuration  tool  that 
could  then  be  used  to  identify  and  thus  re-establish  bindings  and  network 
communications  upon  replacement  of  a  controller  or  device.  A  major  ob¬ 
stacle  is  that  there  are  no  standards/requirements  in  place  (defined)  for 
such  a  tool  suggesting  that  detailed  specification  requirements  would  need 
to  be  developed.  Neither  does  this  approach  seem  to  be  supported  by  in¬ 
dustry;  ASHRAE  135  does  not  define  such  an  object  and  we  are  not  aware 
of  any  proprietary  object  by  any  vendor  that  supports  this.  The  BACnet 
‘Structured  View  Object’,  although  not  yet  available,  might  serve  as  part  of 
the  solution  to  this  problem. 

The  need  for  multiple  tools  will  complicate  O&M  for  Army  maintenance 
staff  due  to  the  amount  of  training  and  higher  skill  levels  required.  Addi¬ 
tionally,  the  large  number  of  tools  that  O&M  staff  will  need  to  be  familiar 
with  will  make  it  very  difficult  to  become  proficient  with  all  of  the  required 
tools.  Finally,  requiring  the  use  of  proprietary  tools  may  give  a  competitive 
advantage  to  vendors  already  established  on  the  installation  since  subse¬ 
quent  vendors  may  have  to  use  the  first  vendor's  tool  during  a  retrofit,  re¬ 
placement,  upgrade,  or  expansion  project. 

This  issue  is  resolved.  It  appears  that  needed  network  communication 
and  binding  requirements  will  require  the  use  of  a  vendor-specific  proprie- 


namic  object  binding  by  Name.  However,  dynamic  binding  is  also  not  required  by  ASHRAE  135,  and  its 
use  and  level  of  support  is  left  up  to  the  implemented  The  result  is  that  in  general  one  cannot  replace 
a  device  and  ensure  that  the  replacement  will  not  “break”  communication  links.  In  general,  the  client 
controller  (the  one  containing  the  identifiers  of  the  remote  device/object/property)  must  be  reconfig¬ 
ured. 
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tary  tool.  Specification  requirements  for  the  documentation  of  inter-device 
communications  will  be  developed. 

3.4.4  Device  Application  Configuration 

Device  configuration,  in  the  sense  of  internal  device  programming  and  pa¬ 
rameters  needed  to  execute  a  sequence  of  operation  (note  in  this  case 
stand-alone  operation  is  discussed,  where  the  network  aspects  of  device 
configuration  were  covered  above)  is  absent  from  ASHRAE  135  and  is  left 
to  individual  vendors  to  implement  as  they  see  fit. 

BACnet  systems,  as  implemented  by  industry,  do  not  support  the  single¬ 
tool  concept.  In  contrast,  with  LonWorks  the  use  of  a  single  network  con¬ 
figuration  tool,  vendor-specific  plug-ins,  and  the  requirement  to  use 
SNVTs,  SCPTs,  or  UCPTs  under  UFGS-15951  and  13801  helps  to  reduce 
the  need  for  proprietary  tools  from  multiple  vendors.  While  it  is  true  that 
when  programmable  controllers  are  used,  both  BACnet  and  LonWorks 
systems  will  require  use  of  a  proprietary  programming  tool,  BACnet  sys¬ 
tems  appear  to  have  a  higher  percentage  of  programmable  controllers  and 
owners/maintainers  of  BACnet  systems  will  be  more  likely  to  suffer  the 
problems  associated  with  using  and  maintaining  multiple  proprietary  pro¬ 
gramming  tools  than  owners/maintainers  of  a  LonWorks  based  system  in 
accordance  with  UFGS-13801  and  15951. 

A  BACnet  system  based  solely  on  ASHRAE  135  (i.e.,  a  system  where  the 
only  requirement  was  compliance  with  ASHRAE  135)  and  using  products 
commonly  available  from  industry  would  most  likely  have  different  pro¬ 
prietary  programming  tools  (for  programmable  controllers)  and  different 
proprietary  configuration  tools  (for  non-programmable  controllers,  that  is 
configurable  or  application  specific  controllers).  Such  a  system  will  com¬ 
plicate  O&M  for  Army  maintenance  staff  due  to  the  amount  of  training 
and  higher  skill  levels  required.  Plus  the  large  number  of  tools  that  O&M 
staff  will  need  to  be  familiar  with  will  make  it  very  difficult  to  become  pro¬ 
ficient  with  all  of  the  required  tools. 

A  further  limitation  of  a  system  based  solely  on  ASHRAE  135  will  be  a  re¬ 
duced  ability  to  perform  remote  configuration.  This  is  due  to  the  fact  that 
ASHRAE  135  does  not  require  a  standard  communications  protocol  be¬ 
tween  the  configuration  software  and  the  device  being  configured.  Ideally, 
a  user  would  wish  to  use  Vendor  A’s  tool  while  sitting  at  Vendor  B’s  work¬ 
station  (front  end)  and  configure  Vendor  A’s  device  that  resides  on  a  build¬ 
ing  network  accessible  via  Vendor  C’s  BACnet  router.  Based  on  industry 
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response  to  a  questionnaire,  configuration  through  a  third  party  BACnet 
router  may  or  may  not  work  depending  on  the  vendor.  Instead,  the  user 
may  need  to  “plug  in”  directly  to  the  LAN  on  which  Vendor  As  device  re¬ 
sides.  Others  advised  us  that  by-and-large  it  can  be  done  and  will  work  al¬ 
though  Telnet/VPN  may  be  needed.  This  is  because  vendors  have  not 
agreed  on  a  standard  manner  to  perform  this  communication.  In  compari¬ 
son,  UFGS-15951  and  UFGS-13801  provides  for  configuration  tool  use 
from  anywhere  on  the  network. 

One  possible  workaround  that  was  suggested  by  industry  experts  is  to  re¬ 
quire  that  all  devices*  have  the  capability  to  be  fully  configured  for  the  in¬ 
tended  application  via  Writeable  properties  of  BACnet  objects.  Device 
vendors  would  then  provide  documentation  of  the  mapping  between  ob¬ 
ject/properties  and  configuration  parameters  (e.g.,  Analog_Value  7,  Pre- 
sent_Value  is  the  Set_Point;  Binary_Value  5,  Present_Value  is  the  flag 
that  indicates  whether  the  VAV  box  has  a  series  fan  or  not;  etc.).  This 
could  then  be  extended  to  require  that  the  contractor  performing  integra¬ 
tion  of  the  device  to  the  front  end  provide  a  page  providing  these  descrip¬ 
tions  and  bindings  to  the  object/properties  to  facilitate  changes  to  them. 
From  a  functional  perspective,  this  is  perfectly  acceptable  and  largely  du¬ 
plicates  the  capabilities  of  LNS  plug-ins  for  device  configuration.  What  is 
unclear  at  this  point  is  how  widely  supported  this  is  by  industry  or  how 
much  this  capability  will  cost.  For  example,  will  this  requirement  force 
vendors  to  use  all  programmable  controllers  because  their  application  spe¬ 
cific  controllers  cannot  be  configured  via  Writeable  properties  of  BACnet 
objects? 

This  issue  is  open.  There  is  uncertainty  about  how  industry  will  view  this 
requirement,  how  much  it  will  cost,  and  whether  it  will  force  the  use  of 
programmable  controllers  exclusively. 

3.4.5  Addressing  and  Naming  convention 

This  is  extremely  important.  For  the  discovery  tools  to  be  effective,  a  logi¬ 
cal  and  consistent  addressing  and  naming  convention,  which  also  results 
in  globally  unique  Device  Identifiers,  is  needed.  Addresses  consist  of  a 


*  This  discussion  originated  with  the  need  to  configure  application  specific  controllers,  however  it  is  also 
applicable  to  programmable  controllers,  where  the  term  “fully  configurable  for  the  application”  would 
not  imply  reprogramming,  but  would  only  refer  to  parameters  (setpoint,  PID  settings,  etc.)  shown  on 
the  Points  Schedule  and  normally  changed  by  the  operators. 
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network  number  (up  to  65,535)  and  a  device  media  access  control  (MAC) 
address.  Device  MAC  addresses  are  unique  within  a  network,  but  not  glob¬ 
ally.  For  ARCNET  and  MS/TP  networks  (up  to  255  devices  per  network 
number),  the  specification  should  require  vendors  to  obtain  address  as¬ 
signments  from  the  owner  if  there  is  any  chance  that  several  vendors  are 
connecting  devices  to  the  same  network  and  therefore  could  repeat  ad¬ 
dresses.  In  any  case,  future  management  of  the  inter-network  will  be  made 
simpler  if  some  logical  address  scheme  is  used  for  all  buildings.  Similarly, 
the  device  object  identification  property  must  be  managed  uniformly  by 
the  owner  of  a  large  system;  no  duplication  is  permitted  in  the  same  net¬ 
work  domain. 

This  issue  is  resolved.  Designers  will  need  to  specify  network  number 
and  MAC  address.  The  specifications  will  provide  addressing  requirements 
and  related  submittals  (such  as  showing  the  addressing  in  a  Points  Sched¬ 
ule). 

3.5  Network  Miscellaneous 

3.5.1  Network  Access  and  DOIM  Coordination 

A  UMCS  ordinarily  if  not  always  requires  access  to  and  use  of  the  base¬ 
wide  IP  LAN.  At  Army  Installations,  this  can  be  challenging  because  sys¬ 
tems  that  use  the  IP  network  must  be  verified  to  operate  at  an  acceptable 
level  of  security  risk.  This  verification  calls  for  DITSCAP/Networthiness 
accreditation/certification.  Obtaining  the  required  certifications  can  be 
painful,  time  consuming,  and  expensive  in  part  because  designers,  Instal¬ 
lations,  and/or  Contractors  sometimes  do  not  foresee  the  need  to  coordi¬ 
nate  with  the  DOIM  as  part  of  BAS/UMCS  projects.  Certification  is  also 
painful  because  the  involved  parties  (DOIM  and  UMCS  project  implemen¬ 
ted)  seem  to  be  unfamiliar  with  each  others  needs  and  intent;  overall 
there  seems  to  be  confusion  about  the  certification  “process.”  This  issue  is 
not  unique  to  BACnet,  but  needs  to  be  addressed  as  part  of  the  design  and 
implementation  process. 

This  issue  is  open  in  that  the  extent  to  which  the  designer  (versus  others) 
needs  to  address  and  be  responsible  for  accreditation/certification  is  un¬ 
clear. 

3.5.2  Media  Types 

BACnet  allows  multiple  media  types,  specifically  ARCNET.  The  problem 
with  ARCNET  is  that  there  is  ONLY  one  major  vendor  who  supports  it;  it 
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is  essentially  a  proprietary  media  type.  In  the  interest  of  standardizing  on 
widely  supported  media,  media  will  be  required  to  be  either  MS/TP  or 
BACnet/IP  over  Ethernet.  The  one  major  BACnet  vendor  who  uses 
ARCNET  may  object  to  this  requirement.  This  vendor  argues  that 
ARCNET  is  faster  than  MS/TP,  therefore  performance  will  be  better  and 
that  media  converters  can  be  used  to  accommodate  ARCNET  and  MS/TP. 
On  the  other  hand,  the  instant  a  particular  LAN  becomes  mixed-media 
(ARCNET  and  MS/TP  with  a  media  converter),  the  speed  drops  to  that  of 
the  slowest  media;  the  performance  advantage  of  ARCNET  vanishes.  Me¬ 
dia  converters  may  require  sole  source  procurement 

This  issue  is  resolved.  Although  there  is  some  slight  industry  objection, 
the  consensus  seems  to  be  that  requiring  MS/TP  (or  IP  only)  is  reasonable. 
There  may  be  special  cases  for  other  media  types,  but  as  with  the 
LonWorks  specification  there  is  no  need  to  deal  with  special  cases  right 
now.  In  addition,  MS/TP  may  eventually  be  phased  out  in  lieu  of  IP. 

3.5.3  MS/TP  Baud  Rate 

BACnet  allows  a  variety  of  MS/TP  communication  rates,  all  the  way  down 
to  9.6  Kbps.  The  network  needs  to  be  able  to  respond  in  a  timely  manner 
to  alarms  and  other  real-time  control  requirements  while  simultaneously 
supporting  near-worst-case  activities  such  as  trending  and  other 
data/network  intensive  activities.  Another  consideration  is  compatibility 
of  different  vendors’  devices  that  operate  at  different  speeds  while  con¬ 
nected  to  a  common  network  bus. 

This  issue  is  closed.  The  requirement  will  be  38.4  Kbps.  It  is  supported  by 
most,  if  not  all,  vendors  and  it  is  reportedly  the  best  speed  for  use  with  leg¬ 
acy  network  cabling.  Some  applications  may  require  faster  polling  and  will 
be  a  designer  option. 

3.5.4  Confirmed  Text  Messages 

The  BACnet  standard  defines  Confirmed  Text  Messages.  Although  its  use 
could  be  used  to  Close  a  system,  response  to  our  industry  questionnaire 
indicated  that  some  vendors  would  object  to  prohibiting  them.  Industry 
does  not  however  seem  to  object  to  prohibiting  them  for  “interoperable” 
communications  (sharing  information  between  devices  or  between  a  de¬ 
vice  and  the  front  end). 
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This  issue  is  resolved.  The  specifications  will  restrict  the  use  of  Con¬ 
firmed  Text  Messages;  language  must  be  developed  to  specify  what  is 
meant  by  “interoperable”  communications. 

3.6  Miscellaneous 

3.6.1  BTL  Listing 

BACnet  Testing  Laboratories  (BTL)  provides  a  “listing”  service  whereupon 
completion  of  laboratory  testing  a  device  becomes  listed  (and  posted  at  the 
BTL  website).  BTL  listing  is,  via  industry  consensus,  a  necessary  but  not 
sufficient  specification  requirement.  The  one  exception  is  the  B-OWS,  be¬ 
cause  there  is  no  test  available  for  this  yet  (as  of  Aug  06),  but  may  be  by 
the  time  BAS  specifications  are  developed. 

This  issue  is  closed.  The  specifications  will  require  BTL  listing  where 
there  is  a  BTL  test  available  although  none  is  presently  available  for  B- 
OWS. 

3.6.2  Source  Code 

BACnet  vendors’  controllers  are  primarily  of  the  programmable  type  (as 
opposed  to  application  specific).  Our  specification  needs  to  make  it  clear 
that  the  customer  “owns”  all  the  control  programs,  graphics,  configuration 
database,  and  other  site-specific  data  including  source  code  for  program¬ 
mable  controllers.  The  vendor  may  copyright  or  patent  the  programming 
tools,  workstation  software,  hardware,  firmware  (including  patented  con¬ 
trol  algorithms),  and  other  features  common  to  their  product  line,  but  the 
customer  should  have  the  right  to  edit,  copy,  or  otherwise  manage  the  site- 
specific  system  applications.  In  general,  industry  appears  to  agree  with 
this  (and  in  one  vendor’s  case  strongly  recommends  it). 

This  issue  is  closed.  The  specification  will  require  source  code  submittals 
as  described  above. 

3.6.3  Mode  Scheduling 

At  a  minimum,  according  to  the  BTL  Device  Implementation  Guidelines,* 
scheduling  should  be  able  to  be  accomplished  using  BACnetBinaryPV 


*BACnet  Testing  Laboratories.  23  March  2006.  Device  Implementation  Guidelines. 
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enumeration  (a  BACnet  property  data  type  which  essentially  is  a  logical 
binary  state  value). 

This  issue  is  resolved.  Functional  and  implementation  requirements 
need  to  be  defined. 

3.6.4  Segmentation 

Segmentation  is  the  breaking  up  of  messages  into  multiple  smaller  mes¬ 
sages.  This  is  a  limitation  on  message  size  imposed  by  the  transport  layer 
(layer  2).  It  appears  as  if  the  specification  should  segmentation.  Some  de¬ 
vices  do  not  support  it,  making  them  incompatible  with  devices  that  do. 

This  issue  is  open.  It  must  be  determined  if  segmentation  is  required  and 
howto  address  this  in  the  specifications. 

3.6.5  Smart  Sensors/Actuators 

BTL  does  not  “list”  any  BACnet  smart  sensors  (B-SS)  and  only  two  ven¬ 
dors’  BACnet  smart  actuators  (B-SA),  where  a  smart  sensor/ actuator  is  de¬ 
fined  here  as  one  that  communicates  digitally.  At  present,  due  to  limited 
B-SS  and  B-SA  device  availability,  permitting  the  use  of  these  devices  may 
restrict/limit  competition  particularly  in  the  case  of  device  replacement. 
This  may  not  be  a  sufficient  rationale  to  prohibit  their  use,  but  the  previ¬ 
ously  discussed  problem  with  discovery  of  slave  devices  may  warrant  not 
permitting  these  devices. 

This  issue  is  open. 

3.6.6  Trending 

Trending  requirements  may  need  to  be  specified,  such  as  where  trending 
data  should  be  stored  and  required  sampling  rates.  One  vendor  indicated 
that  they  can  trend  at  a  minimum  sampling  interval  of  only  10  seconds. 

This  issue  is  resolved;  specification  requirements  must  be  developed. 

3.6.7  Units 

BACnet  defines  an  object  property  “Units”  of  type  BACnetEngineerin- 
gUnits,  which  has  both  SI  and  IP  enumerations.  This  is  a  required  object 
property  for  object  types  Analog  Input,  Analog  Output,  and  Analog  Value. 


ERDC/CERL  TR-07-3 


24 


BACnet  does  not  require  that  a  device  reading  a  value  from  another  device 
also  read  the  units  and/or  convert  units  as  needed.  (These  are  considered 
application  requirements  outside  of  the  scope  of  the  protocol). 

One  solution  would  be  to  require  that  all  devices  that  read  information 
from  another  device  automatically  check  units  and  convert.  This  solution, 
however,  may  prove  infeasible  for  many  controllers  and  can  also  lead  to 
user  confusion  since  not  all  controllers  would  be  using  the  same  units.  An 
alternative  solution  is  to  require  that  all  devices  use  specific  units  for  spe¬ 
cific  values,  either  through  the  specification  of  a  units  system  (i.e.,  “all  con¬ 
trollers  shall  us  SI  units”)  or  through  the  specification  of  units  for  each 
type  of  measurement  (i.e.,  “temperatures  shall  have  units  of  degrees 
farenhiet  [°F],  pressures  shall  have  units  of  PSI”  etc). 

It  appears  that  the  specifications  should  standardize  units. 

This  issue  is  resolved;  units  will  be  standardized,  but  the  method  of  stan¬ 
dardization  has  to  be  determined  and  specified. 

3.6.8  Web-Based  Graphics 

The  possible  use  of  and  requirements  for  web-based  graphics  needs  to  be 
investigated. 

This  issue  is  open.  Further  investigation  is  required  to  determine  if  web- 
based  graphics  should  be  required  or  allowed  by  the  specification. 

3.6.9  XML 

BACnet  use  of  Extensible  Markup  Language  (XML)  appears  to  be  on  the 
horizon.  This  will  have  to  be  monitored  and  the  specification  edited  when 
it  becomes  implemented  as  part  of  the  BACnet  standard. 

This  issue  is  closed  until  a  standard  is  released. 

3.6.10  Structured  View  Object 

The  Structured  View  Object  is  currently  being  defined  by  BACnet 
(ASHRAE).  This  work  must  be  monitored  to  determine  its  impact  on  the 
specifications. 


This  issue  is  open. 


ERDC/CERL  TR-07-3 


25 


3.7  Contracting  Issues/Approaches 

Base-wide  implementation  of  a  multi-vendor  building  automation  system 
(BAS)  entails  the  integration  of  numerous  building-level  systems  where 
the  building-level  systems  are  constructed  individually  as  part  of  sepa¬ 
rate/individual  construction/renovation  projects.  The  integration  aspect 
requires  connection  of  the  individual  building-level  systems  to  a  common 
front-end  platform  (FEP)  in  an  interoperable  manner  using  a  stan¬ 
dard/open  communications  protocol  where  the  FEP  usually  consists  of 
one  or  more  operator  workstations  (OWS)  running  a  single  software  pack¬ 
age  including  related  server(s),  networking,  OWS  software,  etc.  The  FEP, 
via  OWS  permits  monitoring,  management,  and  supervisory  control 
(alarm  management,  trend  data  capture,  on/off  scheduling,  load  shedding, 
etc.)  of  the  many  building-level  systems.  The  UMCS  likely  may  need  to  be 
a  single-source  vendor/contractor  to  supply  workstation  and  related 
hard/software  along  with  system  integration  services  on  a  long  term 
(IDIQ)  contract,  or,  it  may  need  to  require  the  contractor  for  each  build¬ 
ing-level  project  to  perform  system  integration  (to  the  existing  UMCS 
workstation/hardware/software). 

In  addition  to  obtaining/contracting  system  integration  services,  the  pre¬ 
selection  of  building -level  contractors  will  be  helpful  (if  not  necessary)  to 
support  base-wide  implementation  of  a  multi-vendor  BAS  that  uses  an 
open/standard  protocol.  At  various  trade  shows,  the  BACnet  community 
has  advocated  and  demonstrated  the  concept  of  a  plug-fest  where  vendors 
demonstrate  system/equipment  interoperability.  The  Navy  proposed  using 
this  same  plug-fest  approach  as  part  of  a  source  selection  contracting 
process  to  pre-quality  vendors/contractors.  This  idea  shows  great  poten¬ 
tial.  The  Navy  may  need  help  devising  the  contracting  mecha¬ 
nism/approach.  This  may  be  done  on  a  base,  regional,  and/or  national 
(CONUS)  level.  A  regional  or  national  level  approach  seems  most  prag¬ 
matic.  At  the  regional  level  individual  contractors/vendor_branchs  could 
be  evaluated.  At  the  national  level  broader  (vendor  HQ)  support  could  be 
anticipated.  The  intent  is  to  limit  the  controls  vendors  at  each  base  to 
those  who  meet  the  open  system  “requirements.”  Ideally  this  would  limit 
the  number  of  contractors/manufacturers  to  a  “few,”  but  there  is  some 
concern  about  the  break  point  between  acceptable  and  non-acceptable 
vendor  qualifications. 
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4  Conclusions  and  Recommendations 

This  work  identified  and  assessed  design  and  specification  requirements 
for  Open  building  automation  systems  based  on  ANSI/ASHRAE  135-2004 
focusing  on  an  assessment  of  BACnet.  It  identified  issues  in  the  develop¬ 
ment  of  specification  for  an  Open  BACnet -based  BAS  as  well  as  subse¬ 
quent  actions  required  to  address  those  issues. 

This  project  concludes  that  implementing  BACnet  in  an  Open  manner  will 
require  extensively  prescriptive  specifications  (particularly  in  regard  to 
BACnet  “objects”  and  “properties”),  which  would  entail  a  large  design  and 
contract  documentation  effort. 

Although  the  primary  objective  was  to  evaluate  the  feasibility  of  creating 
an  Open  BACnet  BAS  specification  and  not  to  compare  the  BACnet  proto¬ 
col  with  ANSI  709.1  communications  protocol,  the  Government  already 
has  Open  BAS  specifications  based  on  ANSI  709.1  (and  LonWorks  tech¬ 
nology),  and  must  be  careful  to  continue  to  advance  its  open  systems 
goals.  For  this  reason  comparisons  between  an  Open  BACnet  BAS  specifi¬ 
cation  and  the  Open  LonWorks  specifications  of  UFGS-13801  and  15951 
are  included. 

This  work  concludes  that,  while  it  is  possible  to  write  “Open-enough” 
BACnet  BAS  specifications,  the  effort  would  be  challenging  and  prescrip¬ 
tive,  and  would  require  a  greater  level  of  enforcement  than  an  equivalent 
LONWORKS-based  specification.  The  resulting  system  would  not  integrate 
as  tightly  or  be  as  user  friendly  to  installation  operations  and  maintenance 
staff  as  a  LONWORKS  system  based  on  the  existing  UFGS  due  mainly  to 
the  lack  of  a  standard  “network  database”  and  the  need  for  multiple  con¬ 
figuration  tools. 

It  is  recommended  that,  to  support  the  existing  widespread  use  of  BACnet, 
development  of  BACnet  BAS  specifications  should  proceed  in  close  coop¬ 
eration  with  the  Navy  and  Air  Force.  CERL  will  continue  to  meet  with  the 
Navy  on  a  periodic  basis  as  development  of  BACnet  BAS  criteria  proceeds, 
consisting  of  a  building-level  specification,  front-end  (base- wide)  specifi¬ 
cation,  Points  Schedule  drawings,  and  a  source  selection  methodology.  As 
part  of  this,  in  the  near  term,  the  Army,  Navy  and  Air  Force  need  to  agree 
on  control  sequences  and  control  system  diagrams  (drawings)  as  a  precur¬ 
sor  to  the  development  of  BACnet  BAS  specifications.  Existing  LonWorks 
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specifications  and  UFCs  will  then  need  to  be  edited  to  ensure  consistency 
(not  be  repetitive)  with  the  new  BACnet  BAS  criteria,  primarily  in  regard 
to  potentially  common/overlapping  content  such  as  control  sequences  and 
hardware  specifications.  To  obtain  open  systems  in  accordance  with  the 
specifications,  development  of  a  procurement  methodology  is  recom¬ 
mended,  most  likely  via  a  source  selection  process  that  pre-qualifies 
BACnet  contractors. 
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Abbreviations  and  Definitions 


Term 

BACnet 

BAS 

Bl 

BIBB 

BMA 

BTL 

CONUS 

COV 

DDC 

DITSCAP 

DOIM 

ERDC-CERL 

GUI 

HQUSACE 

ID 

IDIQ 

IP 

LNS 

M&C 

MS/TP 

OWS 

PICS 

PVT 

SCPT 

SNVT 

UCPT 

UFC 

UFGS 

UMCS 

XML 


Spellout/  Definition 

Building  Automation  and  Control  Networking  Protocol 
Building  Automation  System 
BACnet  International  (or  binary  input) 

BACnet  Interoperability  Building  Block 
BACnet  Manufacturers  Association 
BACnet  Testing  Laboratories 
Continental  United  States 
Change  of  value 
Direct  Digital  Control 

DoD  Information  Technology  Security  Certification  and  Accreditation  Process 
Directorate  of  Information  Management 

Engineer  Research  Development  Center,  Construction  Engineering  Research 
Laboratory 

Graphical  User  Interface 

Headquarters,  U.S.  Army  Corps  of  Engineers 

Identifier 

Indefinite  delivery  Indefinite  quantity 
Internet  Protocol 

LonWorks  Network  Services.  A  network  operating  system  including  an  image 
(database)  of  the  network  and  devices. 

Monitoring  and  Control  (software) 

Master-slave  /  token-passing 
Operator  Workstation 

Protocol  Implementation  Conformance  Statement 
Performance  Verification  Test 

Standard  Configuration  Parameter  Type.  (LonWorks  term) 

Standard  Network  Variable  Type.  (LonWorks  term) 

User  Configuration  Parameter  Type.  (LonWorks  term) 

Unified  Facilities  Criteria.  (Design  guidance)  Unified  =  Army,  Navy,  and  Air 
Force. 

Unified  Facilities  Guide  Specification.  Unified  =  Army,  Navy,  and  Air  Force. 
Utility  Monitoring  Control  System.  (As  specified  in  UFGS-13801). 

Extensible  Markup  Language 
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